<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Eclipse Platform/Core</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body>

<table BORDER=0 CELLSPACING=5 CELLPADDING=2 WIDTH="100%" >
	<tr> 
		<td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Planning</font></b></td>
	</tr>
  <tr>
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td WIDTH="98%"> 
      <p><b>Current Work</b> </p>
      <p>Work will now be focused on Eclipse 3.0. Rather than rolling out version 
        2.2 which would contain fixes and minor feature requests, it has been 
        decided that we will take on more challenging problems. Please read <a href="http://www.eclipse.org/eclipse/development/why_eclipse_3_0.html">Why 
        Eclipse &quot;3.0&quot;</a>? and the <a href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html">Eclipse 
        3.0 Project Plan</a>.</p>
      <p>Being done concurrently with the 3.0 work are bug fixes for service releases 
        for Eclipse 2.1. For a list of problems which will be fixed for the Eclipse 
        2.1.1 release, check out the Bugzilla bug reports by clicking <a href="https://bugs.eclipse.org/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&product=Platform&component=Core&target_milestone=2.1.1&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=core-3.0&newqueryname=&order=Reuse%2Bsame%2Bsort%2Bas%2Blast%2Btime&field0-0-0=noop&type0-0-0=noop&value0-0-0=">here</a>.</p>
      <p></p>
    
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td WIDTH="98%"> 
      <p><b>Committed Items</b></p>
      <p>[plan item] <i><a href="plan_encoding.html">Improve file encoding support</a></i> - Eclipse 2.1 uses a 
        single global file encoding setting for reading and writing files in the 
        workspace. This is problematic; for example, when Java source files in 
        the workspace use OS default file encoding while XML files in the workspace 
        use UTF-8 file encoding. The Platform should support non-uniform file 
        encodings. [Platform Core, Platform UI, Text, Search, Compare, JDT UI, 
        JDT Core] [Theme: User experience] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37933">37933</a>, 
        <a href="http://dev.eclipse.org/bugs/show_bug.cgi?id=5399">5399</a>)</p>
      <p>[plan item] <i><a href="plan_concurrency.html">Support concurrent activities</a></i> 
        - In Eclipse 2.0 and 2.1, certain operations like builds and searches 
        always run synchronously and block the user at the UI from doing work 
        until the build has completed. The Eclipse Platform should support operations 
        running asynchronously in the background, so that the user is not forced 
        to be entirely idle while long-running operations are in progress. This 
        will likely require an improved concurrency architecture with more explicit 
        rules. [Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE] 
        [Theme: Responsive UI] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36957">36957</a>)</p>
      <p>[plan item] <i>Enable Eclipse to be used as a rich client platform</i> 
        - Eclipse was designed as a universal tool integration platform. However, 
        many facets and components of Eclipse are not particularly specific to 
        IDEs and would make equal sense in non-IDE applications (e.g., window-based 
        GUI, plug-ins, help system, update manager). The Eclipse Platform should 
        factor out and segregate IDE-specific facilities (e.g., everything having 
        to do with workspace resources) so that a subset of it can be used as 
        a rich client platform for building applications. [Platform Core, Platform 
        UI, Platform Update] [Theme: Rich client platform] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36967">36967</a>)</p>
      <p>[plan item] <i><a href="../../documents/user_settings/index.html">Provide user 
        settings</a></i> - It should be possible to store user settings (preferences, 
        compiler settings, repositories lists, etc.) that are not specific to 
        a workspace separate from the workspace, so that they can be used in other 
        workspaces or by other users. [Platform Core] [Themes: Rich client platform] 
        (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36965">36965</a>)</p>
      <p> [plan item] <i><a href="plan_xerces.html">Remove dependency on Xerces</a></i><a href="plan_xerces.html"> 
        </a>- The Xerces plug-in currently provides XML support for the Eclipse 
        platform. XML support is now incorporated into J2SE 1.4, and the presence 
        of the Xerces plug-in can create conflicts. Eclipse Platform should consistently 
        use the built-in XML support that ships with JDK 1.4, or possibly an alternative 
        XML parser such as XMLPull which has a much smaller footprint. [Platform 
        Core] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37696">37696</a>)<br>
        <br>
      </p>
    </td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td WIDTH="98%"> 
      <p><b>Proposed Items</b></p>
      <p>[plan item] <i>Allow editors to open files outside workspace</i> - A 
        common request is to be able to use Eclipse to open a file that is not 
        part of the workspace, or perhaps even one on a remote system. In addition, 
        applications would like to provide file extension associations so that 
        double-clicking on a file in the OS desktop would open the associated 
        Eclipse editor. The operations and capabilities available on these &quot;outside 
        of the workspace&quot; files would need to be defined. [Platform UI] [Themes: 
        User experience] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37935">37935</a>, 
        <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=2869">2869</a>)</p>
      <p>[plan item] <i>Improve workspace synchronization with file system</i> 
        - A file resource in the workspace gets out of sync when the underlying 
        file in the file system is created, deleted, or rewritten outside of Eclipse. 
        File resources usually remains out of sync until the user explicitly hits 
        Refresh. The Eclipse Platform should provide ways to keep the in-memory 
        representation in sync with the file system; for example, by hooking OS 
        file system callbacks where available, and by polling for file system 
        changes in a background thread. [Platform Core, Platform UI] [Theme: User 
        experience] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36962">36962</a>, 
        <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=2360">2360</a>)</p>
      <p>[plan item] <i><a href="plan_content_types.html">Content-type-based editor lookup</a></i> - The choice of editor 
        is currently based on file name patterns. This is not very flexible, and 
        breaks down when fundamentally different types of content are found in 
        files with undistinguished file names or internal formats. For example, 
        many different models with specialized editors get stored in XML format 
        files named *.xml. Eclipse should support a notion of content type for 
        files and resources, and use these to drive decisions like which editor 
        to use. This feature would also be used by team providers when doing comparisons 
        based on file type. The several existing file-type registries in Eclipse 
        should be consolidated. [Platform Core, Platform UI] [Theme: User experience] 
        (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37668">37668</a>)</p>
      <p>[plan item] <i>Improve support for opening workspaces</i> - Many users 
        use multiple workspaces as a way to keep their different projects or work 
        items separate. Currently, this requires launching Eclipse multiple times 
        with different command line arguments, which is not particularly convenient 
        for users. Moreover, when the command line argument is not specified, 
        the workspace location defaults to a directory inside where the code for 
        Eclipse is installed. Eclipse should improve how workspaces get opened, 
        use a user-specific default workspace location more suitable for shared 
        multi-user Eclipse installs, and facilitate switching between workspaces. 
        [Platform Core, Platform UI] [Theme: User experience] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37681"> 
        37681</a>)<br>
        <br>
        [plan item] <i><a href="plan_dynamic_plugins.html">Support adding and 
        removing plug-ins dynamically</a></i> - Installation and configuration 
        of features and plug-ins currently only happens during Eclipse Platform 
        startup. The plug-in registry should be made dynamic so that features 
        and plug-ins can be added or removed without necessarily having to restart 
        Eclipse. This will also entail adding mechanisms for handling the arrival 
        and departure of extensions and extension points. Additional mechanisms 
        such as services will be added to support the dynamic programming model. 
        Alternative runtimes (e.g., OSGi) which offer explicit support for dynamic 
        components will also be investigated and used as appropriate. Plug-in 
        developers will likely require additional support from PDE in writing 
        and debugging well-behaved dynamic plug-ins. [Platform Core, PDE] [Theme: 
        Rich client platform] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37687">37687</a>)</p>
      <p>[plan item] <i><a href="plan_dynamic_plugins.html">Allow plug-in deactivation</a></i> 
        - In order to scale to a large number of plug-ins, Eclipse does not activate 
        a plug-in until its code is actually needed. However, once activated a 
        plug-in remains active for the remainder of the session. Unfortunately, 
        this means that an active plug-in will occupy memory space for its code 
        and objects even if it is only used occasionally. Many users have sessions 
        lasting days or weeks, and this bloat taxes processor memory and JVM performance. 
        The analogy is a long play where the actors enter the stage on cue, but 
        cannot leave it until the play is over. The Eclipse Platform should support 
        plug-ins that can be safely deactivated when the user needs to recover 
        valuable memory space. Another alternative is to provide a way to quietly 
        shutdown and restart the Platform. [Platform Core, Platform UI] [Theme: 
        Rich client platform] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36956">36956</a>)<br>
        <br>
        [plan item] <i>Add a security model</i> - Security needs are pervasive. 
        The Eclipse Platform should provide the basic framework for a security 
        mechanism that can be used by all plug-ins, including a simple credentials 
        store and user authentication. Additionally, key parts of the Platform 
        itself should be secured, such as the ability to install plug-ins, which 
        might need to be restricted in certain products or for certain users. 
        [Platform Core, Platform Update] [Theme: Rich client platform] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37692">37692</a>)</p>
      <p>[plan item] <i><a href="plan_team_integration.html">Improve team control 
        over resource operations</a></i> - Eclipse currently provides limited 
        hooks (edit/save, move/delete) so that team providers can control or influence 
        operations on resources in the workspace. However, there are some aspects 
        and operations over which team providers have little or no influence, 
        such as resource creation and copying. Eclipse should offer team providers 
        better control over resource operations. [Platform Core, Platform Team] 
        (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">37722</a>)</p>
      <p>[plan item] <i><a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/team3.0/logical-physical.html">Support 
        logical resources</a></i> - The Eclipse Platform supports a strong physical 
        view of projects, files, and folders in the workspace. However, there 
        are many situations where a physical view is not the most salient or useful 
        for many purposes. In some cases, multiple distinct objects happen to 
        be stored in a single file, like an archive. Conversely, in other cases, 
        something that is logically a single object is stored across multiple 
        files. This discrepancy between logical and physical creates problems 
        for common operations such as searching, comparing, and versioning, which 
        need to work in the physical realm. Eclipse should support some way of 
        mapping between a logical view and the physical organization of files 
        on disk. [Platform Core, Platform UI] (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">37723</a>)<br>
        <br>
      </p>
    </td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td WIDTH="98%"> 
      <p><b>Other Items</b></p>
      <p><i><a href="../../documents/plan_adapters.html">Improve adapter infrastructure</a></i>
       - there are a number of limitations in the current <tt>IAdapterManager</tt>
       infrastructure.  A number of plan items in platform UI and JDT UI are running up
       against these limitations, so they need to be addressed for Eclipse 3.0.
      <p><i><a href="plan_userexperience.html">Improve User Experience</a></i> 
        - As a first-time Eclipse user there are many non-obvious problems that 
        you can run across and this plan item is being used to collect them all. 
        Some current problems include (but are not limited to): default location 
        of the workspace, separation of user settings and plug-in metadata, multiple 
        workspaces, and translation of messages presented to the user from the 
        Eclipse executable.</p>
      <p><a name="builder_issues"></a>
        <i><a href="../../documents/scoped_builds.html">Improve User Experience for Builds</a></i>
        - Users are confused by certain aspects of the Eclipse build story, and would like
        some increased flexibility in deciding what gets built in large workspaces. This
        proposal deals with making project builds work as the user expects, removing
        confusing build options, and adding the notion of working set builds.</p>
      <p><i>Misc org.eclipse.core.runtime work/investigation:</i></p>
      <ul>
        <li>Look at places in Runtime where we are using Strings and String logic 
          and we should/could replace this with the use of objects like Paths. 
          Need to weigh this against potential performance issues. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=19507">19507</a>) 
        </li>
        <li>The registry cache is complicated. Investigate simplifying it. Ensure 
          to keep the lazy loading work. Are there any other places where we can 
          make similar improvements? (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=27064">27064</a>)</li>
        <li>Provide a specification for plug-in registry resolution. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36504">36504</a>)</li>
        <li>Clear the log file periodically or make it a rolling log file. (bug 
          <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=22765">22765</a>) 
        </li>
        <li>We have had class loader problems w.r.t. #createExecutableExtension 
          for a while. Investigate what we can do to fix these. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=5875">5875</a>)</li>
        <li>Investigate changing the classloader lookup order. parent/self/prereq 
          -&gt; parent/prereq/self</li>
        <li>Make Fragments Real via API? There is currently no way to get useful 
          information about fragments. We need to add to our APIs and make fragments 
          real. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=14460">14460</a>)</li>
        <li>Build Id in Log File - We would like to have the build id in the log 
          file. This needs to be done in conjunction with work from the Update 
          team. We also need to define what a build id is. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=8214">8214</a>)<br>
        </li>
      </ul>
      <p><i>Misc org.eclipse.core.resources work/investigation:</i></p>
      <ul>
        <li>Concurrency issues with the index store (persistent properties and 
          local history)</li>
        <li>New APIs for setting and maintaining file permissions. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=20575">20575</a>, 
          <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26100">26100</a>)</li>
        <li>Change copy/move to merge the source with the destination. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=31883">31883</a>, 
          <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29838">29838</a>)</li>
        <li>Sharing metadata in the repository. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21411">21411</a>, 
          <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26809">26809</a>)</li>
        <li>Markers on non-resources.</li>
        <li>Remote resources -&gt; syncing on existence vs content.</li>
        <li>Make everything a linked resource?</li>
        <li>Add more to the move/delete hook (copy, create, etc). This is related 
          to the Team/Resource Integration plan item. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=13530">13530</a>)</li>
        <li>Lifecycle of persistent/session properties -&gt; what happens on copy/move? 
        </li>
        <li>Lazy persistent properties -&gt; kept in memory and then written out 
          to disk on workspace shutdown/save/snapshot</li>
        <li>When do builders run? <br>
          <ul>
            <li>currently the decorator thread finds a resource which is out of 
              sync but can't do a refresh <br>
            </li>
            <li> builders can only run when you say they can (when you finish 
              an action) <br>
            </li>
            <li>currently you have to think about what you are doing because in 
              some cases you don't want builders to run <br>
            </li>
            <li>shouldn't have to be aware of builders when you are writing the 
              code in your plug-in </li>
          </ul>
        </li>
        <li>Workspace lock granularity. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=35869">35869</a>)</li>
        <li>Delta notification for particular resource types (project, Java, etc) 
        </li>
        <li>Import/Export of preferences...ensure that plug-ins use the Preference 
          mechanism to take advantage of this </li>
        <li>Natures and capabilities (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=31939">31939</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36959">36959</a>)</li>
        <li>Simplier resource model. Resources without builders, markers, etc 
          etc.</li>
        <li>pre-validation of Core API methods -&gt; Can I create this? Can I 
          move this? Request by JDT Refactoring. (really just a request for transactional 
          operations?) <br>
        </li>
      </ul>
      <p><br>
      </p>
    </td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td> 
      <p><b>Deferred Items</b></p>
	  <ul>
      <li>[plan item] Improve local history (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37679">37679</a>)</li>
      <li>[plan item] Add capabilities (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36959">36959</a>)</li>
      <li>[plan item] Support workspace checkpoint and rollback (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=36958">36958</a>)</li>
      <li>[plan item] Improve message bundles (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37712">37712</a>)</li>
      <li>[plan item] Improve plug-in registry (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37715">37715</a>)</li>
	  </ul>
      <p><br>
      </p>
    </td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><p><b>Eclipse 3.0 Top 5 Plan</b></p>
      <p>This is a list of the top 5 items that we will be working on for the 
        rest of the Eclipse 3.0 release cycle. (M7 -&gt; Release)</p>
      <ol>
        <li>Responsive UI 
		  <ul>
            <li>Mainly documentation and client enablement left to do.</li>
            <li>Investigation into current UI performance problems.</li>
          </ul>
		</li>
        <li>User Settings</li>
        <li>File Encodings</li>
        <li>Runtime 
          <ul>
            <li>run from JARs</li>
            <li>enablement (doc, articles, working with other teams, etc)</li>
            <li>robustness/use case coverage</li>
          </ul>
        </li>
        <li>PDE-Build 
          <ul>
            <li>bring up to speed with new runtime requirements (need to build 
              JARs if want to run from JARs!)</li>
          </ul>
        </li>
      </ol>
      <p></p></td>
  </tr>
</table>
</body>
</html>
